Implementing a multi-dimensional unified security and privacy policy with summarized access graphs

ABSTRACT

A computerized method for implementing risk discovery with a set of unified security and privacy policies, includes the step of discovering a set of data and a set of data accesses within an enterprise computing system. The method includes the step of classifying the set of discovered data and the set of data accesses with an identification that shows which of the data assets are important or critical for the enterprise. The method includes the step of determining which of the set of discovered data and the set of data accesses have or are associated with sensitive information. The method includes the step of placing the set of discovered data and the set of data accesses that are associated with sensitive information into a set of discovered information about the infrastructure. The method includes the step of determining which of the set of discovered data and the set of data accesses are relevant in the context of a specified governmental data privacy regulation. The method includes the step of placing the set of discovered data and the set of data accesses that are relevant in the context of a specified governmental data privacy regulation into a set of discovered information about the infrastructure. The method includes the step of, with the set of discovered information about the infrastructure, mapping the set of discovered information about the infrastructure to a set of deterministic dimensions.

CLAIM OF PRIORITY

This application claims priority to U.S. Provisional Patent Application No. 63/153,362, filed on 24 Feb. 2021 and titled DATA PRIVACY AND ZERO TRUST SECURITY CENTERED AROUND DATA AND ACCESS, ALONG WITH AUTOMATED POLICY GENERATION AND RISK ASSESSMENTS. This provisional patent application is incorporated herein by reference in its entirety.

FIELD OF INVENTION

This application related to cloud-platform security and more specifically to an implementing risk discovery with unified security and privacy policies with summarized access graphs.

BACKGROUND

New regulations are currently being applied to data security and data privacy. For example, the European Union (EU) has implemented the General Data Protection Regulation (GDPR) for citizens/residents of the EU. Likewise, the state of California has the California Consumer Privacy Act (CCPA) to enhance privacy rights and consumer protection for residents of California. These new laws and regulations have financial penalties for entities that infringe consumer privacy and data rules. Accordingly, there is now a financial incentive to avoid the financial burden of violating data privacy regulations.

At the same time, innovations in cloud-computing technology have made various previous technologies for protecting data privacy obsolete or anachronistic. For example, using firewalls based on IP based addresses etc. no longer makes sense in some current contexts. Accordingly, improvements to data privacy and data security policies, and automated risk assessments are desired.

SUMMARY OF THE INVENTION

A computerized method for implementing risk discovery with a set of unified security and privacy policies, includes the step of discovering a set of data and a set of data accesses within an enterprise computing system. The method includes the step of classifying the set of discovered data and the set of data accesses with an identification that shows which of the data assets are important or critical for the enterprise. The method includes the step of determining which of the set of discovered data and the set of data accesses have or are associated with sensitive information. The method includes the step of placing the set of discovered data and the set of data accesses that are associated with sensitive information into a set of discovered information about the infrastructure. The method includes the step of determining which of the set of discovered data and the set of data accesses are relevant in the context of a specified governmental data privacy regulation. The method includes the step of placing the set of discovered data and the set of data accesses that are relevant in the context of a specified governmental data privacy regulation into a set of discovered information about the infrastructure. The method includes the step of, with the set of discovered information about the infrastructure, mapping the set of discovered information about the infrastructure to a set of deterministic dimensions.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example process for implementing risk discovery with unified security and privacy policies, according to some embodiments.

FIG. 2 illustrates another process for RC graph implementation, according to some embodiments.

FIGS. 3 and 4 illustrate example equations that can be used to implement process 200, according to some embodiments.

FIG. 5 illustrates an example screenshot showing an equation used to define summary attributes for each service/identity discovered in the detailed access graph, according to some embodiments.

A summarized access graph can be generate using the equation of FIG. 6, according to some embodiments.

FIG. 7 illustrates an example access graph, according to some embodiments.

FIG. 8 illustrates an example summarized access graph, according to some embodiments.

FIG. 9 illustrates an alternative summarized access graph 900, according to some embodiments.

The Figures described above are a representative set and are not exhaustive with respect to embodying the invention.

DESCRIPTION

Disclosed are a system, method, and article for implementing a multi-dimensional unified security and privacy policy with summarized access graphs. The following description is presented to enable a person of ordinary skill in the art to make and use the various embodiments. Descriptions of specific devices, techniques, and applications are provided only as examples. Various modifications to the examples described herein can be readily apparent to those of ordinary skill in the art, and the general principles defined herein may be applied to other examples and applications without departing from the spirit and scope of the various embodiments.

Reference throughout this specification to ‘one embodiment,’ ‘an embodiment,’ ‘one example,’ or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases ‘in one embodiment,’ ‘in an embodiment,’ and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

Furthermore, the described features, structures, or characteristics of the invention may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art can recognize, however, that the invention may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.

The schematic flow chart diagrams included herein are generally set forth as logical flow chart diagrams. As such, the depicted order and labeled steps are indicative of one embodiment of the presented method. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more steps, or portions thereof, of the illustrated method. Additionally, the format and symbols employed are provided to explain the logical steps of the method and are understood not to limit the scope of the method. Although various arrow types and line types may be employed in the flow chart diagrams, and they are understood not to limit the scope of the corresponding method. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the method. For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted method. Additionally, the order in which a particular method occurs may or may not strictly adhere to the order of the corresponding steps shown.

Definitions

Example definitions for some embodiments are now provided.

Application programming interface (API) can be a computing interface that defines interactions between multiple software intermediaries. An API can define the types of calls and/or requests that can be made, how to make them, the data formats that should be used, the conventions to follow, etc. An API can also provide extension mechanisms so that users can extend existing functionality in various ways and to varying degrees.

Application programming interface key (API key) can be a unique identifier used to authenticate a user, developer, or calling program to an API. An API key can be used to authenticate a service with the API rather than a human user.

California Consumer Privacy Act (CCPA) is a state statute intended to enhance privacy rights and consumer protection for residents of California.

Dark web is the World Wide Web content that exists on darknets: overlay networks that use the Internet but require specific software, configurations, or authorization to access.

Deep learning can include various machine learning methods (see infra) based on artificial neural networks with representation learning. Deep learning can be supervised, semi-supervised or unsupervised.

Deterministic dimensions can be a summarized grain of attributes. The deterministic nature of these dimensions are due to the fact that the cardinality of these attributes can be fixed. The intent that is expressed in a set of specified deterministic dimensions can be pre-known/pre-determined.

Distributed version control systems can include Internet hosting for software development and version control. The distributed version-control system can track changes in any set of files. The distributed version-control system can be designed for coordinating work among programmers cooperating on source code during software development.

General Data Protection Regulation (GDPR) is a regulation in EU law on data protection and privacy in the European Union (EU) and the European Economic Area (EEA).

JSON (JavaScript Object Notation) is an open standard file format, and data interchange format, that uses human-readable text to store and transmit data objects consisting of attribute-value pairs and array data types (and/or any other serializable value).

Machine learning (ML) can use statistical techniques to give computers the ability to learn and progressively improve performance on a specific task with data, without being explicitly programmed. Machine learning is a type of artificial intelligence (AI) that provides computers with the ability to learn without being explicitly programmed. Machine learning focuses on the development of computer programs that can teach themselves to grow and change when exposed to new data. Example machine learning techniques that can be used herein include, inter alia: decision tree learning, association rule learning, artificial neural networks, inductive logic programming, support vector machines, clustering, Bayesian networks, reinforcement learning, representation learning, similarity, and metric learning, and/or sparse dictionary learning.

Named-entity recognition (NER) can be a subtask of information extraction that seeks to locate and classify named entities mentioned in unstructured text into pre-defined categories.

Nginx is a web server that can also be used as a reverse proxy, load balancer, mail proxy and HTTP cache.

Open Policy Agent (OPA) can be a general-purpose policy engine with uses ranging from authorization and admission control to data filtering. OPA can provide a unified toolset and framework for policy across the cloud native stack.

Personal data (PII) can be personally identifiable information. PII data can be information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in a specified context.

Risk criticality (RC) can include quantifying the possibility of a service or data being subject to an attack or being a victim of a breach. Criticality can be a measure of sensitivity of data, measured by buckets (e.g. high, medium, low) which can include “code”, PII, personal data, patents, etc.

Runtime application self-protection (RASP) is a security technology that uses runtime instrumentation to detect and block computer attacks by taking advantage of information from inside the running software.

Sankey diagrams are a type of flow diagram in which the width of the arrows is proportional to the flow rate.

Sensitive information is something that scores high in sensitivity like PII data of data subjects, code, patents, personnel information, keys, certifications etc.

Shift-left testing can be an approach to software testing and system testing in which testing is performed earlier in the life cycle of software development.

Software as a service (SaaS) is a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted.

Example Methods

Discovery and Unified Security and Privacy Policies

Example methods can be used to express policy intent around risk, criticality in a multi-dimensional representation and a translation framework for the same to OPA for security policy purposes. For example, example methods can enable a multi-dimensional risk-criticality (RC) representation of enterprise data assets. Based off automated discovery, the RC Graph can be built from the scanned infrastructure. The RC graph can enable enterprises to represent their assets using the deterministic dimensions that the RC Graph can represent with. Additionally, examples of the dimensions that comprise this multi-dimensional representation are discussed infra.

FIG. 1 illustrates an example process 100 for implementing risk discovery with unified security and privacy policies, according to some embodiments. Process 100 provides an RC graph implementation and method to determine a set of deterministic dimensions. In step 102, process 100 discovers data and data access within an enterprise. In step 104, process 100 classifies the discovered data to help the enterprises identify which of the data assets are important or critical for the enterprise. Step 104 can be used to determine which of the data assets have sensitive information. Step 104 can be used to determine which of the data assets and access are important in the context of regulation.

In step 106, from the discovered information about the infrastructure, process 100 can map the info to the deterministic dimensions. In one example, this can be a list of 32 deterministic dimensions (e.g. discussed infra). In step 108, process 100 can let/enable the user/enterprise to express the intent and/or enterprise assets from the specified deterministic dimensions to represent a policy or intent. As noted, in some examples, this can be the thirty-two (32) dimensions discussed infra.

In step 110, process 100 can generate a unified privacy/security OPA policy. This policy can assist enterprises to maintain a desired posture with respect to applicable regulations.

In one example, process 100 can enable a single policy for security and policy Privacy based policy posture for data/zero trust protection. Process 100 can continuously arm an enterprise with a policy that can help with maintaining a posture for a privacy regulation article (e.g. GDPR, CCPA, CIS AWS, CPRA, etc.). Process 100 can provide policy materialization and enforcement. Process 100 can generate a privacy policy (e.g. as a Rego expressed OPA policy, etc.). Process 100 can materialize a privacy policy so that it can be pushed to K8, Kafka, etc. as OPA policies.

An example discussion of various deterministic dimensions is now provided. It is noted that these deterministic dimensions are provided by way of example and not of limitation. Accordingly, other example deterministic inventions can be utilized in other examples. A Data Store (e.g. DS1, DS2, DS3) can be an example deterministic dimension.

An Access Frequency (e.g. minutes, hourly, daily, weekly, monthly, random (e.g. more than once but no fixed pattern), one time, etc.) can be an example deterministic dimension.

An Electronic Identity (e.g. yes, no) (e.g. person or system) can be an example deterministic dimension.

A Role Privileges (e.g. root, open or restrictive access (e.g. are all the permissions being used or there is over provisioning), etc.) can be an example deterministic dimension.

A Multi Service Role (e.g. yes, no) (e.g. specific or multiple (can the role be used to access more than one service)) can be an example deterministic dimension.

A PII-NERs (e.g. name, national id, date of birth (DoB), address, etc.) can be an example deterministic dimension.

A sensitivity status (e.g. personal, code, patents, financial information) (e.g. PII, secrets/keys, personal data, healthcare data/medical record numbers (MRNs), intellectual property—code, patent, financial data, etc.) can be an example deterministic dimension.

An anonymization status (e.g. not anonymized, pseudo anonymized, not applicable (example for non-personal data), etc.) can be an example deterministic dimension.

An access status (e.g. public, enterprise, account, virtual private cloud (VPC), signed access, etc.) can be an example deterministic dimension.

An MFA status (e.g. yes, no, not applicable) can be an example deterministic dimension.

A SaaS status (e.g. Github, Gitlab, SN, SFDC) can be an example deterministic dimension.

An API access status (e.g. Yes, No) can be an example deterministic dimension.

A Keys Managed by a key management service (KMS) status (e.g. Amazon Web Services (AWS), HashiCorp-Vault, Azure, GCP, Other) can be an example deterministic dimension.

A Role status (e.g. Access Identity's Role) (e.g. HR, Payroll, Engineering Mgr, Core Banking (Electronic Identity) Role, etc.) can be an example deterministic dimension.

An API Path (e.g. /employee/add, /employee/list, /vendors/list/, /reports/list, etc.) can be an example deterministic dimension.

A Service status (e.g. API Gateway—AG01, S3-S01) can be an example deterministic dimension.

An Access Identity (e.g. Supreeth, Aria, Ravi, Core Banking) can be an example deterministic dimension.

A Service status (e.g. API Gateway—AG01, S3-501) can be an example deterministic dimension.

An Encrypted status (e.g. Yes, No) can be an example deterministic dimension.

An Access status (e.g. Public, Enterprise, Account, VPC) can be an example deterministic dimension.

An Access Logging Level (e.g. Info logging enabled, Secrets/PH leaking in logs, etc.) can be an example deterministic dimension.

A Storage Delete Protection status can be an example deterministic dimension.

A Last Access Time (e.g. Data Minimization) (e.g. 30 days, Last Qtr, Last six months, Year, 5 years, etc.) can be an example deterministic dimension.

A Dark Web status (e.g. Data Seen On Darkweb (Pastebin, etc.), Interest Noted On Dark Web, etc.) can be an example deterministic dimension.

An Access Location (e.g. USA, Germany, India) can be an example deterministic dimension.

A Subject Residency (e.g. Germany, India, USA, UK) can be an example deterministic dimension.

A Service Location status (e.g. Primary Location (US-east-1a, US-east, US-east-2a), Backup Location (US-west-1a, US-west, US-west-2a), etc.) can be an example deterministic dimension.

A Vendor/Vendor Location (e.g. US-east-1a, US-east, US-east-2a) can be an example deterministic dimension.

A Data Location (e.g. Primary Location (US-east-1a, US-east, US-east-2a); Backup Location (US-west-1a, US-west, US-west-2a); etc.) can be an example deterministic dimension.

A Service Image Posture (e.g. How: AMI/Container Image Registry Scan) can be an example deterministic dimension. This can include any Vulnerabilities Levels Present (e.g. Critical [9, 10], High [7, 9), Medium [4, 7), Low [0.1, 4), etc.). This can include Cipher Suites (e.g. Scanner Integration—Qualys/Nessus/AWS Inspector/ . . . ). This can include vulnerabilities exploited (e.g. RASP integration).

A File Malware Scan (e.g. of S3, Box, etc.) can be an example deterministic dimension.

A Risk level (e.g. High Medium Low) (e.g. driven by a known template, like PII data, or exposed to the internet or likes, which customers can customize if need be) can be an example deterministic dimension.

FIG. 2 illustrates another process 200 for RC graph implementation, according to some embodiments. It is noted that process 200 can be utilized by process 100 and/or vice versa in various embodiments.

In step 202, process 200 can define data assets. Process 200 can define summary attributes for each data asset. For example, process 200 can use the following categories for summarization. This can include a criticality value. The criticality value can determine how critical is a data asset to the organization. There can be three levels of criticality: high, medium, low. Process 200 can use a region value (e.g. determine where the data asset is located; etc.). Process 200 can use a protection status value (e.g. determine the data asset protected using encryption; determine if it kept in clear-text; etc.).

Process 200 can use a privacy value (e.g. Does the data asset anonymize PII data; etc.). Process 200 can examine PII entities, categories, etc. Process 200 can use an access value (e.g. Does the data asset contain personal information; Does it contain confidential information; etc.).

An example list of summarized values for access types of a data asset is now provided. This can include, inter alia: Public; Non-Public (e.g. personal information (PI) (e.g. user data); confidential insider enterprise only; partner only; vendor-only; namespace; etc.). Furthermore, process 200 can determine if the organization associates a tag, such as a scope or a namespace, for the data asset. For example, process 200 can determine if the asset used in production, stage, and/or development deployments. This namespace attribute can be defined by the customer. Also, this could be inferred from an existing tag in the data asset metadata. FIGS. 3 and 4 illustrate example screen shots of equations 300 and 400 that can be used to implement process 200 (e.g. step 202), according to some embodiments. Equation 300 can provide an access graph. Equation 400 can be used to generate the access graph, and can be defined as: d₁,T(d₁).

In step 204, process 200 can define summary attributes for each service/identity discovered in the detailed access graph. Process 200 can define summary attributes for each service/identity discovered in the detailed access graph. These attributes can be specific to each data asset that the service/identity is accessing. The following categories can be used for summarization. Process 200 can use a risk value (e.g. determine if there a risk associated with the service/identity. Process 200 can use three levels of risk quantification: high, medium, low.

Process 200 can use a region value (e.g. determine a region where the service is located). Process 200 can assume role constraints (e.g. determine a type of identity that is used to access the data asset; determine if there is a person identity or a system; etc.).

Process 200 can use an API/key based identity. For example, the following can be a list of summarized values for this attribute: person or system open or restrictive access specific or multiple (not instances of the same service).

Process 200 can use a frequency value (e.g. determine the frequency of access; determine if an event occurs periodically (e.g. scheduled) or randomly (e.g. from an API call)).

Process 200 can use a namespace value. For example process 200 can determine if the organization associates a tag, such as a scope or a namespace, for the service or identity. For example, process 200 can determine if the service or identity is used in a production, stage, development deployment(s). The namespace attribute can be defied by the customer. Additionally, it can be inferred from an existing tag in the service/identity metadata.

FIG. 5 illustrates an example screenshot 500 showing an equation used to define summary attributes for each service/identity discovered in the detailed access graph, according to some embodiments. For example, in the above example access graph, a₁,B(a₁,d₁) for service a₁ accessing can be defined as follows: B(a₁,d₁)=[<low, us-west-1, system-open-specific, periodic, prod>].

In step 206 process 200 can generate summarized access graph from outputs of steps 202 and 204. Formally, summarized access graph can be generate using the equation of FIG. 6, according to some embodiments.

FIG. 7 illustrates an example access graph, according to some embodiments. It is noted that the edges of the access graph can be associated with the operation performed by a service or an identity on a data asset (e.g. captured as the color of the edge in the underlying access graph). Access graph identifies what kind of the operation does the service/identity makes on the data asset. Operations can be, inter alia: create, read, list, write, delete, uncategorized, etc. Uncategorized indicates that what could not determine semantics of the operation.

More specifically, example access graph 700 is illustrated. Access graph 700 includes an AWS Lambda L₁ 702 function that reads from a HTTP endpoint D₁ 708, processes the data, and writes to an S3 bucket D₂ 710 (e.g. using Roles R₁ and R₂ 704 and 706 respectively).

FIG. 8 illustrates an example summarized access graph 800, according to some embodiments. Summarized access graph 800 can be generated from the same context as access graph 700. Summarized access graph 800 includes nodes 802 and 804. It is noted that both data assets are low-critical containing non anonymized non-public data (e.g. accessible only by the enterprise) in the clear. Also, Lambda L₁ 702 can use a system identity with restrictive access that is specific for Lambda L₁ 702. Summarized access graph 800 can be generated from example access graph 700.

Based on summarized access graph 800, h some illustrative examples of access patterns are provided. In the PROD namespace, a low-risk service/identity assumes a system identity that is restrictive and specific for that service to read a low critical data assert containing non-anonymized non-public data (e.g. accessible only by the enterprise) in the clear. Likewise, in the PROD namespace, a low-risk service/identity assumes a system identity that is restrictive and specific for that service to write a low critical data assert containing non-anonymized/non-public data (accessible only by the enterprise) in the clear.

FIG. 9 illustrates an alternative summarized access graph 900, according to some embodiments. Summarized access graph 900 can include nodes 902-906. As an alternative setup, consider that Lambda L₁ 702 uses a restrictive identity to read and a broader identity that allows write access to more that one bucket to write the data. Again, summarized access graph 900 can be generated for access graph 700. It is noted that when a drill-down is performed on a service graph, it can expand to the detailed access graph representing the actual services/identities and data assets that are involved in the particular subgraph of SG that was selected for the drill-down.

Example Use Case

RC graph or the multi-dimensional model can be used to represent many use cases. Three illustrative examples are now discussed. A set of data stores (e.g. RDS, DynamoDB, etc.) may include PII information. Accordingly, these stores should be encrypted and no outside VPC access to these stores. In another example, there may data access from outside the location of an AWS, GCP or Azure region. Accordingly, there may be a need to block such an access at an API gateway. In another example, a new API token can be provided on a new path alert when the request/response involves sensitive information (PII, Company Confidential, Code, Patents).

The RC graph dimensions can be used to represent this issue. For a set of data stores (e.g. RDS, DynamoDB, etc.) if there is any PII information in these stores, the store can be encrypted such that no outside VPC access to these stores is available. There can be four (4) dimensional layers in this example: data store (e.g. DS1, DS2, DS3); sensitivity (e.g. PII, code, patents, financial information); encrypted (e.g. yes, no); access (e.g. public, enterprise, account, VPC); etc.

It can be determined if there is data access into a VPC happening from outside the location of an AWS or GCP or Azure region. This access can be blocked at an API gateway. There can be three dimensional layers in this example: cloud provider (AWS, GCP, Azure, Oracle, IBM); region (US-West-2, us-west?-b, us-westl-a, west US 2); service (API Gateway—AGO?, S3-S01). Here, the service is the service which the access from an outside cloud provider is accessing.

In another example, a new API token can be seen on a new path alert only when the request/response involves sensitive information (e.g. PII, Company Confidential, Code, Patents). Here the four (4) dimensional layers can be: access identity (e.g. Supreeth, Aria, Ravi, Core Banking); API path (/employee/add, /employee/list, /vendors/new); service (e.g. API Gateway—AG01, S3-S01); sensitivity (PII, Code, Patents, Financial information); etc.

CONCLUSION

Although the present embodiments have been described with reference to specific example embodiments, various modifications and changes can be made to these embodiments without departing from the broader spirit and scope of the various embodiments. For example, the various devices, modules, etc. described herein can be enabled and operated using hardware circuitry, firmware, software or any combination of hardware, firmware, and software (e.g., embodied in a machine-readable medium).

In addition, it can be appreciated that the various operations, processes, and methods disclosed herein can be embodied in a machine-readable medium and/or a machine accessible medium compatible with a data processing system (e.g., a computer system), and can be performed in any order (e.g., including using means for achieving the various operations). Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. In some embodiments, the machine-readable medium can be a non-transitory form of machine-readable medium. 

What is claimed by United States patent:
 1. A computerized method for implementing risk discovery with a set of unified security and privacy policies, comprising: discovering a set of data and a set of data accesses within an enterprise computing system; classifying the set of discovered data and the set of data accesses with an identification that shows which of the data assets are important or critical for the enterprise by: determining which of the set of discovered data and the set of data accesses have or are associated with sensitive information, placing the set of discovered data and the set of data accesses that are associated with sensitive information into a set of discovered information about the infrastructure, determining which of the set of discovered data and the set of data accesses are relevant in the context of a specified governmental data privacy regulation, placing the set of discovered data and the set of data accesses that are relevant in the context of a specified governmental data privacy regulation into a set of discovered information about the infrastructure; and with the set of discovered information about the infrastructure, mapping the set of discovered information about the infrastructure to a set of deterministic dimensions.
 2. The computerized method of claim 1, further comprising: enabling the enterprise to select a subset of deterministic dimensions from the set deterministic dimensions to represent a policy or intent.
 3. The computerized method of claim 2, further comprising: providing an Open Policy Agent (OPA) as a general-purpose policy engine that implements a set of authorization and admission control to data filtering operations based on the selected subset of deterministic dimensions.
 4. The computerized method of claim 2, further comprising: generating a unified privacy and security OPA policy, wherein the unified privacy and security OPA policy assists enterprises to maintain a desired posture with respect to the specified governmental regulations.
 5. The computerized method of claim 4, wherein there are thirty-two (32) deterministic dimensions.
 6. The computerized method of claim 5, further comprising: generating a Risk criticality (RC) graph based on the subset of deterministic dimensions.
 7. The computerized method of claim 6, wherein the governmental regulation comprises the General Data Protection Regulation (GDPR).
 8. The computerized method of claim 6, wherein the governmental regulation comprises the California Consumer Privacy Act (CCPA).
 9. The computerized method of claim 10, wherein the RC graph quantifies a risk of a service or a data being subject to a cyber attack.
 10. The computerized method of claim 1, wherein a deterministic dimension has a cardinality of fixed attributes.
 11. The computerized method of claim 10, wherein an intent expressed by a specified set of deterministic dimensions is pre-defined. 